With the emergence of 3G mobile telephony, new communication technologies have been developed providing greater network capacity and higher transmission rates. For example, GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) technologies are used to support wireless multimedia telephony services requiring a wide range of data rates and different protocols. The trend today is also a move towards packet-switched transport, providing greater flexibility and utilization of available communication resources.
Further, new sophisticated terminals are rapidly emerging on the user market, having high resolution colour displays and various codecs (coders/decoders) for communicating audio and visual information in different formats. The multimedia services may involve communication of data representing voice, images, text, documents, animations, audio files, video files, etc. in a multitude of different formats and combinations.
A prevailing goal or ambition in the field of telecommunication is to converge all services on to a single packet-based transport mechanism: the Internet Protocol (IP), regardless of the type of services, access networks and technologies. Therefore, a service network architecture called “IP Multimedia Subsystem” (IMS) has recently been developed by the 3rd Generation Partnership Project (3GPP) as an open standard, to give operators of access networks the ability to offer multimedia services in the packet domain.
Basically, an IMS service network comprising various different network elements can be integrated with any type of access network and is independent of the access technology used, provided that the access network can meet the service requirements in terms of bandwidth, QoS (Quality of Service), etc. Hence, IMS is a platform for enabling services based on IP transport, basically not restricted to any limited set of specific services.
A communication protocol called SIP (Session Initiation Protocol) has been defined by IETF (Internet Engineering Task Force) as a generic session management protocol for handling a wide range of IP-based services. SIP is a signalling protocol for creating, modifying and terminating communication sessions with one or more participants. SIP is also an application-layer protocol running on top of several different transport protocols. Either UDP (User Datagram Protocol), TCP (Transport Control Protocol) or SCTP (Stream Control Transmission Protocol) can be used as a transport mechanism for SIP messages. When sending SIP messages, an addressing element called “SIP URI” (Uniform Resource Identifier) is used to indicate the source and destination, respectively, of the communicated SIP messages.
FIG. 1 generally illustrates a basic network structure for providing multimedia services by means of an IMS service network. It should be noted that the figure is greatly simplified and shows only a selection of network nodes needed to understand the context of the present invention. A calling mobile terminal A is connected to a first radio access network 100 and communicates with a called mobile terminal B connected to a second radio access network 102, in a communication session S involving one or more multimedia services. Alternatively, terminal A may communicate with a fixed terminal or computer or a content server delivering some multimedia content to the terminal, such as a piece of music, a film or a game.
An IMS network 104 is connected to the first radio access network 100 and handles the session with respect to terminal A, as initiated by its the user. In fact, the IMS network 104 receives and processes any service requests made by the user of terminal A. In this example, a corresponding IMS network 106 handles the session on behalf of terminal B, and the two IMS networks 104 and 106 are controlled by different operators. Similarly, the IMS network 106 receives and processes any service requests made by the user of terminal B. In the following description, the IMS network 104 of the calling party terminal A will be considered, although the described functions and procedures may also work in IMS network 106 just as well. Alternatively, terminals A and B may of course be connected to the same access network and/or belong to the same IMS home network.
In general, multimedia services are always handled by the home IMS network of the subscriber, and in the shown scenario, terminals A and B are connected to their respective home IMS networks. On the other hand, if both terminals A and B belong to the same home network, only one IMS network would handle all service requests from terminals A and B.
The illustrated session S is managed, using SIP signalling, by a node called S-CSCF (Serving Call Session Control Function) 108 assigned to terminal A in the IMS network 104, and the used multimedia service is enabled and executed by a SIP application server 110. Basically, the S-CSCF node 108 serves as a proxy for the SIP application server 110 towards terminal A and sends SIP messages from terminal A to the IMS network 106 of terminal B, as indicated by a dashed arrow. Further, a main database element HSS (Home Subscriber Server) 112 stores subscriber and authentication data as well as service information, among other things, that the SIP application server 110 can fetch for executing services for subscribers. The S-CSCF node 108 may also fetch information from the HSS 112 to determine which application server 110 to handle a service requested by terminal A, as determined by “triggers” in the HSS 112.
A node called I-CSCF (Interrogating Call Session Control Function) 114 is connected to other IMS networks, in this case network 106, and acts as a gateway for SIP messages from other IMS networks. I-CSCF 114 receives SIP messages from the IMS network 106 of terminal B, as indicated by another dashed arrow. Another node called P-CSCF (Proxy Call Session Control Function) 116 acts as an entry point towards the IMS network 104 from any access network, such as network 100, and all signalling flows between users and the IMS network 104 are routed through the P-CSCF 116. The various functions of the I-CSCF and P-CSCF nodes 114, 116 are not necessary to describe here further to understand the context of the present invention. Of course, the IMS network 104 contains numerous other nodes and functions, such as further S-CSCF nodes and SIP application servers, which are not shown here for the sake of simplicity. Basically, the IMS network 106 comprises the same type of nodes as network 104.
The shown SIP application server 110 may be configured to provide one or more specific multimedia services to subscribers. The workload on certain SIP application servers can be substantial and may increase rapidly so that individual servers becomes overloaded, at least during limited time periods. SIP application servers are therefore often built as clusters with a plurality of similar server units, hereafter referred to as “traffic modules”, each being capable of basically performing the functions required from the application server. To overcome temporary overloading problems in application servers, further traffic modules can be added in an application server to meet a higher load. Thus, a particular application server typically comprises a plurality of such traffic modules and a “load sharing” function for distributing the work load among the traffic modules. In this way, a scalable server with a cluster of traffic modules is provided, which is transparent so that only a single “virtual” server is seen. Scalability is thus achieved by adding or removing traffic modules in the cluster.
FIG. 2 illustrates schematically the SIP application server 110 of FIG. 1 in more detail, adapted to handle service requests from subscribers. The front-end of the server 110 is a receiving unit 200 having a load balancing function LB, configured to schedule incoming service requests R to different traffic modules 202a, 202b, 202c, 202d . . . . Each one of the traffic modules is capable of processing requests according to the service(s) implemented in the server 110. The scheduling of incoming service requests to different traffic modules can be made in different ways. Basically, any of the traffic modules can either be selected, e.g. randomly or according to a “Round Robin” schedule or the like, or the same traffic module can be selected repeatedly for a specific user by using a hashing algorithm always providing the same result, e.g. by using a constant value associated with the user or session as input to the algorithm.
In WO 03/069473 and WO 03/069474, some solutions for load sharing and data distribution in servers using load balancing functions are described. In these known solutions, a user identity is used as input to a hashing algorithm to provide the same server for different requests from a specific user.
When a SIP application server activates a service for a subscriber, a created session identity, “call ID”, is used as a reference to the ongoing session. Further, various session specifics are also determined, such as subscriber data, service parameters, codecs (coders/decoders), protocols, multiplexing schemes, etc., which are used during the session. Necessary session data/information is therefore fetched from the HSS 112, and some may also be read in communicated SIP messages. This data is then temporarily stored in the application server throughout the session.
If the application server contains a cluster of traffic modules, the session information can either be stored in a common database in the server, available to all traffic modules, or locally in a specific traffic module assigned for the session. In the former case, any traffic module can handle an ongoing session by fetching necessary session information from the common database, which is however considered to be a relatively complex situation resulting in increased latency. In the latter case, any subsequent requests requiring the stored session information must be directed to that particular traffic module, sometimes referred to as session “affinity” or “stickiness”. In the case of HTTP-based messages, the load balancing function is normally responsible for always selecting the same traffic module during a session. The load balancing function may then use a suitable hashing algorithm, as described above, using a session specific value as input to provide the same traffic module.
When SIP-based “Voice-over-IP” services are executed, it is possible to use an application-layer load balancing function known as a “stateless load balancing SIP proxy”, one example of which is an implementation called the “Vovida Load Balancer”. The Vovida Load Balancer distributes incoming requests to different identical servers, such that all users can direct their requests to the same SIP URI address, and the Load Balancer will assign servers dynamically to handle each request. Each request is forwarded to the next available server that appears on a predetermined list of associated servers, i.e. according to a “Round Robin” schedule. The Load Balancer then receives responses and then forwards them back to the requesting party.
The Vovida Load Balancer adds its own SIP URI address in a “Via” address field in the header of an incoming SIP request packet, before transferring the packet to the assigned server, in order to receive a subsequent response from the server which is then forwarded to the requesting party. In the case of TCP-based transport, a “sliding window” mechanism is used for reliably streaming application data between IP endpoints. At the TCP layer, the endpoints are not aware of any delimiters in the data stream, essentially meaning that SIP messages are not distinguished. The Vovida Load Balancer thus works at the application level, receiving the TCP stream and handling the SIP messages as such.
“Stickiness” may thus be obtained by applying a hashing algorithm using a value derived from the “CallID”, “To”, “From” tags, as an input value to the algorithm. This value is called the “Dialog Identifier”. However, it is a problem that a hashing algorithm must be applied each time in order to reach the same traffic module, since significant processing resources are consumed in the process. Such a solution requires that the cluster front-end stores data (as a hash table) related to a transaction between requests.
However, since the Vovida Load Balancer does not store data between transactions, it cannot even ensure that requests within a SIP dialog are consistently directed toward the same traffic module. Therefore, all traffic modules must use a shared database or the like for storing the state of any given SIP dialog. As the cluster front end handles SIP traffic in this way, substantial added complexity is introduced that may lead to software failure and added maintenance costs for the software product over time.
Thus, using hashing algorithms and/or common databases will generally not provide a satisfactory solution for obtaining load balancing and session affinity in this context, as explained above.
US 2003/0074467 A1 discloses a plurality of recipient servers 308a-d in communication with a load balancer 304, where each recipient server is associated with different unique service port numbers assigned to that recipient server, and common redirect port numbers assigned to a group of recipient servers. The first data packet transmitted by a client server 302 includes a destination port number, and is first received at the load balancer. If the destination port number matches one of the unique service port numbers, the load balancer sends the data packet to the corresponding recipient server. If the destination port number matches one of the common redirect port numbers, the load balancer selects a recipient server in the corresponding recipient server group and sends the data packet thereto.
The selected recipient server then sends a response to the client server including a redirect flag set to a service port number, associated with that recipient server, to which the client server must send subsequent data packets. In the solution presented in US 2003/0074467 A1, the recipient server is thus initially identified and selected depending on the destination port number given in the first received data packet.